Simulink™ from The MathWorks, Inc. of Natick, Mass., is an example of a graphical modeling environment, specifically a block diagram environment. Simulink™ allows users to create a pictorial model of a dynamic system. The model consists of a set of symbols, called blocks. Each block can have zero or more input ports, output ports, and states. Each block represents a dynamic system whose inputs, states, and outputs can change continuously and/or discretely at specific points in time. The lines are used to connect the blocks' ports to one another, and represent data dependencies between blocks. Signals may be represented as values traveling along the lines that connect the blocks in a block diagram.
If all of a block's inputs, states, and outputs change either continuously or at one fixed, periodic rate, the block is considered to be a ‘single-rate’ block. If the inputs, states, and outputs update, either together, or separately at points in time defined by two or more rates, the block is considered to be a ‘multi-rate’ block. If a model has multi-rate blocks in it, or two or more single-rate blocks running at different rates, then the model itself is multi-rate (vs. single-rate).
A block is referred to as ‘atomic’ if its functional definition is outside the context of the model in which it is placed. Simulink™ has a set of predefined atomic blocks (e.g. Sum, Product, Gain), and the user can also create their own atomic blocks through user-written ‘S-functions’. Being atomic, S-functions' functional definitions are specified outside the context of the model, for example using C code or MATLAB ‘m’ code. A ‘composite’ block is a block whose functional definition is specified through the model, using sets of atomic and composite blocks. Simulink™ permits the user to specify ‘subsystems’, composite blocks whose definition consists of interconnected sets of predefined blocks, user-written S-functions, and other Simulink™ subsystems. Subsystems can be nested hierarchically, defining a ‘model hierarchy.’
Simulink™ sample rates provide a mechanism for specifying how often components of a model execute. FIG. 1 depicts an example of the use of sample rates in controlling the execution of model components. For example, the designer may specify that a plant block 4 executes at a continuous rate, and a controller block 10 executes at some periodic, discrete rate. The execution of model components is scheduled by the Simulink™ infrastructure when simulating, or by the operating system for a real-time implementation. There is no causal relationship between the dynamics of the model and the scheduling of these rates; the instants at which the components execute are predetermined.
Simulink™ supports the propagation of sample rates. For example, the rates of the Gain blocks 8 and 12 in FIG. 1 may have been left unspecified, or rather, specified as “Inherit”. In this case, assuming that the rates of the plant 4 and controller 10 blocks have been specified, the Gain blocks 8 and 12 inherit their rates from the plant and controller blocks.
Simulink™ also provides mechanisms for specifying causal relationships between the dynamics of the model and the execution of model components, including: function-call subsystems, triggered subsystems, iterator subsystems, action subsystems and enabled subsystems. The specifying of causal relationships permits users to specify execution of model components conditional on present and past values of signals and other data in the model.
However, the scope of conditional execution is generally restricted to a subsystem as conventional methods of specifying the relationships do not allow the scope of conditional execution to be defined as an arbitrary set of blocks (as opposed to the set of blocks that comprise a subsystem). This is a significant limitation, since there are times where it is desirable to simultaneously execute a set of blocks that are not in a subsystem and/or are not contiguous in the model. For example, conventional methods of conditional execution do not allow execution of various blocks distributed throughout the model at power-up or power-down. As a result, the manner in which the causal relationships may be composed is restricted. Conventional methods of specifying the causal relationships between the dynamics of a model and the execution of model components do not allow a user to enable half of the blocks in a subsystem and trigger the other blocks. Similarly, one may not trigger some of the blocks in a subsystem with one trigger, and the remaining blocks with a different trigger.
An additional drawback to conventional mechanisms for specifying the causal relationships between the dynamics of a model and the execution of model components is that these mechanisms require graphical connections to be made in the block diagram to indicate causality. This can result in an appearance which some users feel “clutters” the diagram. Another limitation to conventional mechanisms for specifying causal relationships is that the conventional mechanisms do not naturally map to advanced software or operating system constructs, such as initialization, exceptions, or tasks. Similarly, since conventional mechanisms of specifying the causal relationships lack a first class object associated with the causal relationship, it is difficult to configure and assign characteristics to that relationship. It is also difficult for the user to directly leverage implicit dynamics associated with the mechanisms, for example the enable and disable methods associated with an enabled subsystem, and to conditionally execute components of the model based on these implicit dynamics.